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REAL TIME PROCESS FOR DEFINING. PROCESSING AND 
DELIVERING A HIGHLY CUSTOMIZED CONTACT LIST OVER A NETWORK 

Background of the Invention 

5 Field of the Invention 

Aspects of the present invention generally relate to the real-time definition, processing and delivery of 
contact address lists over a network. More particularly, embodiments of the present invention relate to selecting 
contact records for any geography of any size or shape that have a propensity to consume a specific product or 
service, and delivering these records with selected information appended, such as a contact name and a consumption 
10 propensity score, in a real-time environment over a public network such as the Internet. 
Description of the Related Technology 

Traditionally, the process of selecting and extracting records from a national contact list of 100 million plus 
records was limited to batch processes on large mainframe computers housed at companies such as ACXIOM, 
MetroMail and Polk. These lists were mainly used for direct marketing applications such as direct mail and 
1 5 telemarketing. These historical tape-oriented databases contained large records. They were typically several hundred 
bytes in size and contained separate fields for name, contact addresses: (USPS mailing address, city, state, ZIP code; 
telephone number, e-mail address, etc.) and various levels of geography, household and individual attribute data like 
age, income, presence of children, etc., as well as other data like geodemographic codes and composite social 
economic scores. 

20 Based on the extremely large size of the database and sequential processing r^uirements. the definition of 

list selects and appends involved multiple people and took several days, since processing was usually organized around 
a large weekly batch run that processed all pending orders. The resultant list was usually only available on magnetic 
media such as nine-track tape that was then mailed or delivered by courier to the mail fulfillment house. 

Custom geography selects like radius and polygons were not available. This factor, in conjunction with the 

25 long turn-around times, limited the usefulness of these lists for non-direct marketing contact applications like public 
safety notification of toxic spills, etc. 

Product scoring models were limited to large mailers like Readers Digest that could afford to build a custom 
usage model using the attribute data on these files as independent variables. The list provider would then program this 
model and use it in the list select process. The building and programming of these models was usually a nuilti-month 

3D process and was a minimum of several hundred thousand dollars in costs. 

In the mid 1990's, a CD based product called 'Pro CD' made available key-entered data from the national 
white pages. Pro CD packaged and marketed the resulting database on eight regional CD-ROMs in retail computer 
stores, like Comp USA, for approximately $100 for both the software and the data. Initially, the software was 
primarily oriented to directory assistance applications. When the user typed in a name and city, the product would 

35 return a list of names, address and phone numbers. Later generations of the product had the address records United 
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States Postal Service (USPS) ZIP coded, appended 5-digit ZIP code latitude and longitudes coordinates, and provided 
easy to use mailing and telephone number list select and extract software. The software supported geography selects 
such as State, NPA, NPANXX, City Name, ZIP code or an approximate radius around a selected record in the database. 
All the records for the same 5-digit zip code were assigned the same latitude and longitude coordinate, which made it 
5 easier to select a targe radius like 25 miles rather than having to provide a large list of zip codes. There was no ability 
to assign a particular latitude and longitude and then generate records around this latitude and latitude point. This lack 
of geographic precision eliminated applications like direct mail to custom pizza store delivery polygons or mailing to 
high potential Digital Subscriber Line (DSL) custon^s with a high propensity to own a computer that live more than 
2.5 miles from their telephone switch. DSL connecthrity is currently limited to about 2.5 miles from a telephone 

10 company central office switch. 

The contact list functionality and quality of the Pro CD product was limited by four factors. The first was 
that telephone book addresses are generally incomplete since many listings contain only a name and no address, 
secondary addresses like apartment number are rarely provided, and it is a difficult process to accurately translate a 7- 
digit telephone number and a partial street address and determine the correct NPA (area code) and city. These white 

15 page address deficiencies result in a mailing list with poor USPS deliverability as well as a deliverable list with very 
sparse coverage. A USPS mail deliverable contact list is a list where all the records are deliverable by the USPS to the 
addresses shown on the list. The second forntation was that there was no attribute date on the database to perform 
any meaningful selects. The third factor was the white pages for a given directory are published only once a year and 
about twenty percent of telephone listing change every year, which means that many records on the database are out 

20 of date. This high rate of white page listing changes coupled with the previously described correct NPA assignment 
issues and a targe number of NPA splits occurring after the white pages were printed also made the quality of 
telemarketing or telephone number contact lists generated by the product somewhat less than desirable. The fourth 
factor is it is a messy and time consuming process required to manage an eight CD-ROM database on a PC that 
normally only has a single CD-ROM drive. 

25 In the last few years, the major contact list suppliers like ACXIOM, MetroMail and Polk have made 

significant improvements in their database quality, depth of data and have migrated many of their databases from tape 
to disk storage. They have also provided electronic specification interfaces to their large customers to perform online 
counts. The method of performing these counts is usually from pre-stored geography summary tables. This method 
works well as long as the number combinations of geography and selecting or screening data is restricted to a finite 

30 number of permutations. However, the nearly infinite number of possible permutations using geography definitions of 
any area of any size and shape as well as product scores on thousands of products that are Geography, Household and 
Individual (GHI) data dependent which require real time computation, makes this method of pre-stored tables 
impractical. 

Currently, there are web sites that provide some type of Internet based direct marketing list definition, 
35 ordering and delivery. However, none off the following Web sites: OataByAcxiom.com; lnfoUSA.com; 



•2- 



wo 02/29675 PCT/USOl/30863 

MyProspects.com: QMSoftcom; ThinkDirectMarketinoxorrv !ra-OnDemand.com or ListsNowxom provide anything 
close to the meeting the current industry needs. None of the above Web sites provide a mapping interface to provide 
an easy way to define and process custom geographic areas of any size or shape. None of the above web sites provide 
a way for scoring individual records in a list based on the consumption of a specific product or service. None of the 
5 web sites provide results in real*time and pushes the results to a user-specified node. None of the web sites provide a 
way to store a customized service area around a set of stores and permit the user to go back at a later time and 
generate a fresh new list for a selected set of stores without having to re-specify the service location geographic area 
and select criteria. 

There is currently a definite need in the industry to provide a nearly 1 00% contactable, multi-application list 
10 in a real-time environment over a network. More specifically, there Is a need for a user, using an interactive detailed 
street map as a reference, to easily specify a geographically defined trade area of any size or shape, select a 
consumption score above a cutoff value from a database containing several thousand product/services scores, select 
from a rich list of additional data from which they want to select or append, and have the resultant list returned to a 
network node of their choice within a few seconds after they approve the specifications, counts, and costs. In 
15 addition, there is a need for a multi-location user that does a monthly direct marketing campaign like a pizza chain 
doing a direct mailing around their stores, to define thar polygon service areas using the above tools and save their 
select, append and geographic definitions. For their periodic mailing, they could generate a new fresh list for each 
store by simply selecting the store's saved maO spedfication record of the stores for which they want to do the 
mailing. 

20 Such a system would allow the us^ to interface to the real-time contact list system over a secure public 

network with either a browser or a customized applet embedded into another application running on a client device. 

Summary of the Invention 

In one aspect of the invention, there is a computerized real-time, interactive method of building a list of 
contact records based on selected criteria, the method comprising obtaining a geographic area definition, a 

25 classification and a threshold value associated with the classificatioa generating a search geography code list of 
geography codes based on the geographic area definition, determining a selected set of records in a list database based 
on the geography codes in the search geography code list, identifying a spatial coordinate and a socio-economic code 
corresponding to a sub-geography code for each record in the selected set of records, identifying a classification score 
for each record in the selected set of records based on the socio-economic code, and determining identified records in 

30 the selected set of records based on a comparison of the classification score with the threshold value and if the spatial 
coordinate associated with the record is located within the geographic area definition. 

In another aspect of the invention, there is a real-time, interactive method of building a contact list based on 
selected criteria, the method comprising permitting a user to interactively generate a list specification in real-time, 
transmitting the list specification over a network to a server having a memory, and building a contact list on the server 

35 in real-time based on the list specification, wherein the contact list comprises a plurality of records. 
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In another aspect of the invention, there is a real-time, interactive method of building a contact list based on 
selected criteria, the method comprising interactively generating a list specification in real-time, and building a contact 
list on a server in real-time based on the list specification record. 

In another aspect of the invention, there is a real time, interactive method of building a contact list on a 
5 computer network based on selected criteria, the method comprising interactively generating a list specification in real- 
time, comprising interactively specifying a geographically defined area for which a contact list is desired including 
receiving user input, and interactively selecting a product from a plurality of products and a threshold score for the 
product including receiving user input; transmitting the list specification over the computer network to a server having 
a memory; building the contact list on the server in real-time based on the list specification; and transmitting the 
10 contact list to a user-specified node on the computer network if one or more characteristics of the contact list are 
approved by a user. 

In another aspect of the inventioa there is a system for interacthrely generating a contact list in real-time 
based on selected criteria, the system comprising a server connected to a network, means for interactively generating 
a list specification in real-time, means for transmitting the list specification to the server via the network, means for 

1 5 building a contact list on the server in real-time based on the list specification, and means for transmitting the contact 
list to a user-specified node on the network if one or more characteristics of the contact list are approved by a user. 

In yet another aspect of the invention, there is a computer syst^n for interactively buOding a contact list in 
real time based on selected criteria, the system comprising a user specification process module configured to recehre 
user input so as to interactively generate a list specification in real-time, a geography list process module configured to 

20 receive the list specification and to generate a list of selected geography codes in real-time based on the list 
specification, a list select and data append process module configured to generate an intermediate list in real-time 
based on the list of selected geography codes and the list specification, and a contact item lookup process module 
configured to build a contact list in real-time based on the intermediate list. 

Brief Description of the Drawings 

25 Figure 1 is a block diagram of a networic for interactive, on-line generation of contact lists of the present 

invention. 

Figure 2 is a block diagram of databases, files, or tables and lists utilized in the interactive, on-line generation 
of contact lists. 

Figure 3 is a flowchart of a process for generating contact lists corresponding to the structures defined in 

30 Figure 2. 

Figure 4 is a block diagram of databases, f ileSi or tables, processes and lists utilized in the interactive, on-line 
generation of contact lists. 

Figure 5 is a diagram representing the relationships of the structures and processes of Figure 4. 
Figure 6 is a flowchart of a process for generating contact lists corresponding to the structures defined in 
35 Figures 4 and 5. 
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Rgure 7 is a flowchart of the Generate List of Latitude/Longitude Windows function shown in Figure 6. 
Figure 8 is a flowchart of the Screen and Build Raw List function shown in Figure 6. 
Figure 9 is a flowchart of the Lookup and Build Rnal Contact Records function shown in Figure 6. 
Figure 10 is a flowchart of the Synchronize Databases function shown in Figure 8. 
5 Rgure 1 1 is a flowchart of the Record Screening function shown in Rgure 8. 

Detailed Description of the Preferred Embodiments 
The following detailed description presents a description of certain specific embodiments of the present 
invention. However, the present Invention may be embodiol in a multitude of different ways as defined and covered by the 
claims. In this description, reference is made to the drawings wherein tike parts are designatol with like numerals 
10 throughout. 

Referring to Rgure 1, an exemplary networit configuration 100 used by the present invention will be 
described. A user 101 communicates with a computing environment that may include multiple server computers or a 
single server computer in a client/server relationship on a computer networic 120, such as the Internet. In a single 
server configuration, a web server 140 may include the capabilities of a production server 150, such as a contact list 

15 build server. Alternatively, the web server may communicate with one or more production servers, such as production 
servers 150 and 152, via a local area network (LAN) or a wide area networic (WAN) 130. The server computers may 
be connected via the networic 130 to a networic gateway 12Z which provides access to the network 130 via a high- 
speed, dedicated data circuit for example. 

In a client/server environment, the web server computer 140 includes a server program which comnujnicates 

20 with one or nnore client interface devices 102-108. In one embodiment, the client devices 102-108 (which may be 
referred to as nodes) connect to the computer networic 120 through one or more Internet Service Providers (ISPs), such 
as ISP 110. ISPs are also called Internet Access Providers (lAPs). The ISP 110 may provide Internet access to 
individual users and/or provide a direct connection from a company's networks to the Internet. 

The client devices may include a persona) computer 102 running an applet, such as a Java applet. 

25 Alternatively, the personal computer 102 may be running a browser program such as described below. A portable or 
mobile computer 104 may communicate with the ISP 110 with a modem or with a wireless connection interface 
device. Other client devices include a Web TV device 106 or a handheld access device 108, such as a personal digital 
assistant (PDA) or a mobile telephone with the capability of Internet connectivity. For high volume users, a 
workstation (or server) 1 1 2 may communicate through the ISP 1 1 0 directly to one or more production servers 1 50/1 52 

30 using a Remote Procedure Call (RPC) or socket interface via the Internet IP network. Alternatively, a woricstation (or 
server) 114 may bypass the ISP 110 by connecting directly to the Internet via a backbone provider, for example. 
Workstations 1 12 or 1 14 do not need to use the hypertext transfer protocol (HTTP) and may bypass the use of the 
web server 140. 

Yet other hardware configurations may be used to convnunicate with the server computers. If the web 
35 server computer 140 is equipped with voice recognition or DTMF hardware, the user 101 could communicate with the 
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server program by use of a telephone. The server would then provide information to the user or receive from the user 
so as to interactively generate a contact list via the telephone. Other connection devices for communicating with the 
server computers may include, for example, a cable interface device connected to a visual display, or a satellite dish 
connected to a satellite receiver and a television. For convenience of description, each of the above hardware 
5 configurations is included within the definition of the client devices. Other alternative ways of allowing communication 
between the user 101 and the server computers may also be employed. 

The server computers 140, 150, 152 and the client devices 102-108 may each have any conventional 
general purpose single- or multi-chip microprocessor such as a Pentium* processor (e.g.. Pro, II. Ill), an AMD Pentium 
dass or better processor, a 8051 processor, a MIPS* processor, a Sun SPARC2 or UltraSPARC2 processor, a Power 

10 PC* processor, or an ALPHA* processor. In addition, the microprocessor may be any conventional special purpose 
microprocessor such as a digital signal processor or a graphics processor. Furthermore, the server computers and the 
client devices may be desktop, server, portable, hand-held, set-top, or any other desired type of configuration. 
Furthermore, the server computers and the client devices each may be used in connection with various operating 
systems such as: UNIX, LINUX, Solaris, Disk Operating System (DOS), VxWorks, PalmOS, OS/2, Windows 3.X, 

1 5 Windows 95. Windows 98, Windows CE, Windows NT, or Windows 2000. 

The server computers and the cii^t devices may each Include a network terminat equipped with a video 
display, keyboard and pointing device. In one embodiment of the network confrguration 100, the client devices may 
include a network browser that is used to access the web server computer 140. In one embodiment of the invention, 
the network browser is the Internet Explorer, licensed by Microsoft Inc. of Redmond, Washington. The browser nriay 

20 include a graphical user interface to f adiitate conununication with the user, such as to display information to the user 
or request information from the user, so as to interactively generate the contact list. In other embodiments, other user 
interfaces may be utilized to communicate with the user. 

The user 101 at one of the dient devices 102-108 may utilize the browser to remotely access the web 
server program using a keyboard and/or painting device and a visual display, such as a monitor. It is noted that 

25 although only several dient devices are shown in Figure 1, the network configuration 100 can indude hundreds of 
thousands, or more, of client computers. 

The processors of the servers and/or client devices execute software and operate on databases, files, tables, 
lists and the like. The software may include processes, functions, procedures and the like, which may be represented 
by blocks or states in the subsequent figures. The terms module and process are used herein to refer to software 

30 and/or processors operating under control of software to perform defined functions or tasks. The functions, 
processes, and so forth can be divided or partitioned in many ways and may be performed by a processor under control 
of software instructions. 

The network 120 may include any type of electronically connected group of computers induding, for 
instance, the following networks: a virtual private network, a public IntOTiet a private Internet, a secure Internet a 
35 private networic. a public networic, a value-added networic, an intranet and the like. In addition, the connectivity to the 
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network may be, for example, by remote dialup modem, cable modem Digital Subscriber Line (DSLh ISDN. T1. Ethernet 
(IEEE 802.3). Token Ring (IEEE 802.5). Rber Distributed Datalink Interface (FDD!) or Asynchronous Transfer Mode (ATM). 
The network 120 may connect to the client device 102, for example, by use of a modem or by use of a network 
interface card that resides in the client computer 102. 
5 Referring to Figure 2. a high-level block diagram 200 of the major database and process components of the 

present invention will be described. The blocks or elements of Figure 2 may represent databases and results such as 
lists or files. The blocks of subsequent figures may also represent processes, functions, procedures, calculations, 
subroutines, and the like. 

Block 202 represents the results of a specification process of specifying the requirements for a contact list. 

10 These results are referred to as a list specification record. In one embodiment, this involves several components that 
fall into four primary categories: screening/selecting, appending, formatting and delivery specification. 

Screening/selection can also be further divided into major subcategories: spatial geography, product/service 
consumption values/scores, geography/househotd/individual (GHI) attributes, address types and data quality. Examples 
of spatial geography screening are selecting records located: within an irregular shaped pofygori; within a defined radial 

15 distance around a specified address, intersection, latitude and longitude defined point; or within a list of standard 
geographies like zip codes, DMAs (Dominant Marketing Areas), cities, places, counties, states, NPAs (Area Codes), 
MCDs (Minor Civil Divisions). MSAs (Metropolitan Statistical Areas), congressional districts, voting precincts, school 
districts, etc. 

In terms of product/service consumption, there are many ways to implement this screening and/or append 
20 feature. Note that the term 'product* may be used hereafter to refer to a product, a good, a service, or the like. The 
product may be identiried by a classification and may refer to a class of goods, a particular good, a specific brand, and 
so forth. Examples of three of the common consumption screening methods for consumer lists are regression models 
based on individual, household or geographic data; neural network models; and panel consumption data used in 
conjunction with an individual, household or geography based segmentation system. Examples of consumer 
25 segmentation systems are MicroVision. LifeP^YCLE. PRIZM. and P$YCLE by Claritas; ACORN by CACI; The Life Style 
Selector by Polk; Mosaic, Insource and Niches by Experiaa* Solo and Portrait by Translinion; etc. In 
business/government list applications, the same consumption screening methods apply; however, the key 
discriminatory data in one embodiment is a combination of SIC (Standard Industrial Classification). SOC (Standard 
Occupational Classification) distributions by SIC and number of employees at a location. 
30 Geography/Household/lndividual (GHI) screening is usually based on demographic characteristics at one or 

more of the GHI levels: examples are age, income, marital status, own/rent, gender, race, property value, age of 
children, presence of children, education level, occupation, age of dwelling units in area, type of automobiles owned, 
boat ownership, and the AMA 'do not mail to' flag. etc. Again, business/government screening is usually based on 
some combination of SIC, SOC and number of employees. 
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Address type is obviously a function of the type of contact address: U.S. mailing address, telephone number, 
etc. For a U.S. mailing address, the valid USPS (United States Postal Service) address types are Firra High-rise (Multi- 
unit), Single unit. RR or HC Box, PO Box and General Delivery, while Telcordia currently classifies telephone phone 
types as Plain Old Telephone Service (POTSL pager, cellular, PCS, Mobile, Marine Mobile, etc. Data quality screening 
5 relates to records that are missing some key quality component. A non-inclusive list of examples includes records 
without a name, records with a missing address component such as apartment number or telephone numbers without 
an area code, records with a missing screening/append attribute component and records that have an old confirmation 
date. 

In general, the data that can be appended In a contact list is substantially similar to the data that can be 

10 used to select from. However, some of the data available for selecting may be suppressed from appending to protect 
consumer privacy. Application specific examples include non-published telephone numbers, e-mail addresses, children's 
names and ages and income. There are also behind-the-scene data elemmits that can be appended, but do not make 
sense to be selected in their raw form. Examples of common appended variables of this type are latitude and longitude 
or oth^ small area geographies like MCDs, census tracts, block groups or blocks, as well as the distance and direction 

1 5 from a retail location to a detail record's address for records that are inside a selected radius or polygon. 

Formatting specifications fall into several levels or areas such as mixed case or all capital letter mailing 
addresses, whether the first address line of a mailing address should be a single field or whether there should be 
separate fields for building number, proKlirection, street name, street type, post directioa secondary address type and 
secondary address number. The next level of formatting is the file type: whether it should be a fixed field text file 

20 terminated by a Windows CR-LF or a UNIX new line, an ASCII delimited record file, an application specific file like a 
native Microsoft Access or Excel file or an XML (Extended Markup Language) stream etc. The next level of formatting 
relates to sending the file in raw form or compressing it with a compression utility like PKZIP. 

The final level of delivery specification relates to the address to which the list could be delivered 
electronically. Options include one or more of the following: a user's browser, a file on a user's hard drive, a user's e- 

25 mail address, a third party e-mail address, IP address, URL or a RP site. The above are all classified as "put" options. 
There are also "pull" options where, upon list completion, a notification process e-mails the file, statistics and costs to 
an e mail address that includes the FTP site and password from which the full list can be retrieved. 

Databases 210 include the data sets utilized by the specification process to generate the list specification 
record 202 to provide a user-friendly environment for specification. The data sets contain a list of geography types 

30 with each geography type containing a list of geographies identified by both a code and a name. Examples of the 
geography types are listed in the section related to the record 202 above. For example, there are 3141 counties in the 
United States and the county list contains the counties in alphabetic name order by state. In one embodiment, the 
code is the FIPS (Federal Infomnation Processing Standard) 2-digit state code followed by the 3-digit county code. For 
example, San Diego County, CA has a FIPS code of 06073. 
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When a custom geography is required, databases 210 fulfill this requirement for record 202 with detail street 
mapping and address latitude and longitude coding databases and database access tools. The original source of these 
mapping databases is usually some combination of the 1990 Census TIGER files and the USPS AMS address-coding 
guide in one embodiment. These files have been either enhanced or merged and enhanced by private companies like 
5 GOT (Geographic Data Technology), Navtecti or Etak. These enhanced databases are then utilized by software 
programs such as that from QMS (Qualitative Marketing Software), Mailers software.com and Group One for address 
latitude and longitude coding. This kerne! level address coding functionality software and data is then enrtbedded into 
map display software APIs (Application Program Interfaces) like those provided by MapQuestxem, ESRL Maplnfo and 
AutoCAD. These mapping software packages and application developer kits usually provide both a Java and a C 

10 API that allows an application developer to easily develop both Web and non-Web applications with both a mapping and 
address to latitude and longitude geo-coding user interface. Using these databases and tools, an application developer 
can provide a simple user interface that provides a user the ability, for example, to type in an address or intersection 
and have a detailed street map appear on their screen with the entered address or intersection displayed in the center 
of the map. The user can then easily enter a radius around this location or digitize a polygon that follows boundaries 

1 5 like streets, rivers or railroads. 

In one embodiment, databases 210 also provide a list of products/services that can be scored by the system 
as mentioned above. The basis for these scores, as mentioned above, may be regression-based equations, neural 
network determined pattems or the integration of panel data from sources like MRI (MediaMark Research Inc), NPO 
(National Panel Data), Simmons, GDR Crest, etc., with a segmentation system like the ones mentioned above. In 

20 addition to product scores, databases 210 also provide a data dictionary that can be used by the application as a way 
of showing the user what data items are available for list select and append. 

A list, such as a Zip Code list, of block 204 results from an equivalency process that takes the list 
specification record 202 and then uses databases 220 to build an intermediate list of linkage keys or linkage key 
parent keys. For example, if the linkage key is a ZIP +6, then valid linkage parent keys could be a 5-digit zip code, a 

25 ZIP-t-2 or a ZIP<»>4. The primary purpose of this process is to build a subset list of records to be searched in the 
master database, thus eliminating records from being searched that cannot possible meet the geographic select 
criteria. 

Databases 220 are a set of geography translation files that are used in building the intermediate linkage key 
list 204. Two examples are a spatial coordinate, e.g.. latitude and longitude, window to 5-digit zip code equivalency 

30 file, and a county to 5-digit zip code equivalency file. Note that spatial coordinates herein include entity pairs such as 
latitude and longitude, which may be interieaved as a single number. For example, when a user defines their geography 
select as a radius around an address or a digitized polygon around an address, there needs to be a way to translate 
these spatial definitions into a standard set of geography codes to reduce the number of candidate records that must 
be searched in the detailed record database. In a database with 140 million detail records, there are approximately 

35 43,000 5 digit zip codes. A one-mile radius definition using the latitude and longitude window to zip code equivalency 
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file" will normally return a list of one to three 5-digit zip codes to search. This nfiakes a search improvement of over 
10,000 times when compared to searching all detail records in 43,000 zip codes sequentially, or using a secondary 
index and having to make many thousands of random disk accesses using convention relational databases with 
secondary indexes. The same type of search efficiency improvement can also be done for the county to zip code 
5 equivalency file mentioned above. The equivalency files are used to keep the detailed master record file in only one 
sequence so as to be able to process it in relatively small sequential, discrete disk or memory blocks by translating alt 
geographic definitions to one common geographic definition consistent with the order of the detail record master 
databases. 

A list of block 206 results from a select and append process that uses the linkage key list or parent linkage 

10 key list of block 204 in conjunction with other specification parameters originally defined in block 202 and inherited by 
block 204 to efficiently access databases 230. The select and append process th^ builds a raw list of all records 
that pass the specified selection criteria and appends all selected data items to each passing record. The process to 
generate the raw list 206 performs precision spatial screening as it detunes if a detail record is located inside a 
radius or polygon or its county code matches one of the selected counties. Records that fail this test are not sent to 

15 the intermediate raw list file. The select and append process also screens out records that fail to pass productlservice 
minimum/maximum score thresholds as well as performing alt other screening and append functions defined above in 
conjunction with the record of block 202. 

Databases 230 can be one database with many fields of data or multiple databases where each database 
only contains a few data fields and each database cari be of a different linkage key precision within the same linkage 

20 key family. For example, in the tat^ case, one database could be zip code (5-digit) based, another ZIP-i-4 based, 
another ZIP+6 based and one could be ZIP+6 based with name pointer codes. Historically, most direct marketing 
systems used a single database with many data fields, which typically included name, contact addresses (USPS 
mailing (billing and delivery), telephone number, facsimile number, electronic-mail, etc.), product scores, demographic 
variables and geography codes. This type of single database design is simplest to implement but has major 

25 shortcomings in terms of flexibility and processing speed. With the advent of faster computers having more computer 
memory, the multiple database design becomes more attractive. Computer RAM (Random Access Memory) provides 
approximately 10,000 times faster data access speeds than disk drives. Based on this performance ratio, a superior 
design in terms of processing speed and flexibility is to utilize multiple parallel linkage key sorted and indexed 
databases that utilize storage efficient pointers to other memory databases versus storing fully expanded records in a 

30 single file. For example, Frank N. Stansberry, 123 N Mount Wilson Btvd Apt 1202A, Little Rock, Arkansas, 12345- 
6789-12 can be stored in twehre binary bytes of linkage keys and pointers to other memory resident databases. The 
above storage efficiency used in conjunction with parent linkage key databases, like a ZIP-*-4 to latitude and longitude 
database, a MicroVision ZIP-4-4 Segment Directory and a fifty segment MicroVision product score table, provides a 
way to efficiently determine which of the twelve-byte detailed records are located within the specified geography 

35 definitions, as well as to determine which records have a high propensity to consume a specified product or service. 
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The multiple database design version of databases 230 also adds flexibility to the system by making each 
database related to all other databases based on the common linkage key hierarchy, yet remaining totally independent 
from one another. The following examples illustrate the flexibility and database independence of the multiple database 
design using a single hierarchical linkaga key. A linkage key to spatial coordinate database, which may be the ZIP'»-4 
5 to latitude and longitude database, could be replaced with a ZIP+6 latitude and longitude database; additional 
MicroVision Scores tables could be added without impacting any existing databases; segmentation systems and their 
dependent products scores tables could be interchanged; additional demographic variable databases could be added at 
any level of geography supported by the linkage key, etc. 

The records of block 208 result from a lookup process that utilizes the intermediate raw list 206 and 

10 databases 240 to generate a full name and address (or other contact items) record from which the process builds the 
final record containing a name and address as well as selected append data to the format specified by the user in the 
list specification record 202. In one embodiment, the final records form a mailing list. In another embodiment fields 
or items other than name and/or physical address may be utilized for the final records, and these records may form a 
contact list or other type of list. If a single or fuHy expanded record multiple database design was used in databases 

15 230, then the lookup process and databases 240 would not be required. In one embodiment the method used by the 
lookup process to generate fully expanded name and address records is extremely fast since all records from databases 
240 are stored in computer memory. 

The lookup process includes processes that are conceptually identical for expanding names and addresses. 
However, the address expansion process is a function of the contact address type and may involve a few additional 

20 tables. In order to simplifY the description, only the name expansion process is discussed herein. The intermediate 
raw list file 206 contains three pointers stored as binary numbers: a last name pointer, a first name pointer and a 
middle initial pointer. These pointer values, illustrated here as base 10 numbers, correspond to fixed size record 
sequence numbers loaded in three corresponding databases. For example, if the last name pointer value is 30.1 11, 
then the lookup process would retrieve record 30,1 1 1 or "O'Delt* from the last name memory resident database. This 

25 same simple process is used to retrieve the first name and middle initial creating a name like 'John R O'Deir. In one 
embodiment the retrieve name is in mixed case and contains special characters, like the apostrophe between the 0 
and the D in 'O'Deir. By storing the last name G'Dell only once for all the hundreds of thousands of instances of the 
last name O'Dell, the name can be stored and retrieved in the most common and desirable format. If a user specified to 
have names with all capital letters without any special characters, it is a simple computer conversion to convert 

30 "O'Deir to "ODELL*. However, if one stored the full name in databases 230 as *ODELL', there is no standard 
algorithm to convert "OOELL" and like names to the mixed case, most desirable fonnat. This same process and 
process benefits also apply to business names as well as to the various types of contact addresses. 

In a USPS mailing address contact list embodiment databases 240 are created from three primary public 
sources: The United States Postal Service (USPS), The United States Census Bureau, and the National White pages. 

35 The USPS provides a monthly version of the AMS ZIP +4 address coding guide and the City State file. Using these 
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fiies and indexing them by some hierarchical geographic component level of a ZIP code, an 11 -digit zip code can be 
converted to a complete mailing address like "123 N Main St APT 3B, Portland OR". The primary source of first and 
last names is that compiled by the United States Census Bureau for the 1990 Census and provided as a downloadable 
file from their web site. These Census Bureau names have been augmented by extracting and tabulating both first and 
5 last names from the commercially available national white pages provided by companies like ACXIOM Corporation. All 
names over a certain frequency that can be verified as a valid name are added to the master lists. This same process 
is used for compiling a master list of businessfgovernment names. This process also provides the ability to eliminate 
erroneous names from the master name databases and to do some OTor correction when the database pointers are 
created. For example, there are over 3,000 first names of "DAIVD" in the national white pages. This obvious typo is 

1 0 assigned the same pointer value as "David", so even though the source was wrong, the name generated by the lookup 
process for this record would be "David" and not "DAIVD". When the results of the 2000 Census are made available, 
the new information may be utilized in place of the 1990 data. 

In another onbodiment the records of block 208 may contain nan^ or portions of names (e.g., first name 
only) and telephone numbers* facsimile numbers, electronic addresses such as e-mail addresses, network addresses, 

15 universal resource locators (URLs), Internet Protocol (IP) addresses, pager numbers or other wireless device numbers 
corresponding to the names instead of names and addresses. In other embodiments, other data, such as telephone 
numbers, business identifier and telephone number, residence name and telephone number, electronic-mail address, IP 
address, URL and so forth may be listed in place of the names and addresses. 

The above description of Figure 2 discusses one embodiment of this invention utifizing currently available 

20 technology. This process involves selecting records from a unhrerse of over 100 million records and delivering, in a 
single network session, a multi-application contact list containing many thousands of records with selected data 
appended that has been screened to be within a geography of any size and shape and/or optionally screened for a 
propensity to consume or use a specific product or service. The embodiment described above uses multiple compact 
databases with pointers and a universal linkage key using a Postal 11 -digit zip code with name pointers, as an 

25 example, to associate matching records in different databases with different geographical hierarchical levels of 
precision. With the rapid development in computer memory, processing speed, and overall computer technology, one 
skilled in the art may be able, at some point in the future, to accomplish the above novel functionality using either a 
different universal linkage key and/or a more classical single database design for list applications other than classical 
direct mail. For example, the linkage key could be a telephone number, census block number, network logical address 

30 like an e-mail address, network physical address like an IP address, interieaved coordinate pair like a latitude and 
longitude, etc. In the case of the IP address, the ZIP+4 to lat/lon tables would be replaced with an IP address to 
current location latflon table and the ZIP+4 to geodemographic table would be replace by an IP address to 
geodemographic table. Using the above embodiment, a retailer could utilize the system to generate a list of potential 
customers currently located within a two mile radius around the retailer's store that have a high propensity for 

35 purchasing a product that the retailer just put on sale. Immediately upon receipt of the list, the retailer could 

•12- 



wo 02/29675 PCT/USOl/30863 

broadcast an instant message to all list record addresses that have their fixed location or mobile IP device set to 
accept such messages. This same type of process could be used by a public safety organization to notify a list of 
people down-wind of a toxic chemical spill for example. One can see from the above examples, the near instant 
availability of custom contact lists for geographies of any size or shape with optional screening used in conjunction 
5 with existing list mergelpurge technology and developing network broadcast technologies makes many new 
applications possible. 

The description of Figure 2 as described above relates primarily to specifying and generating a single, one- 
time list for a geography of any size or shape. Rgure 2 also illustrates the processes used by a multi-location retailer 
to specify each location only once and then periodically generate new updated lists around each specified location 

10 using the saved specifications. Referring to Figure 2, the multi-locations process works as follows. For each location, 
the user only performs the specification steps described above for databases 210 and record 202 and saves the 
specification record to a list specification record 202 that includes a location name or identification (ID). In one 
embodiment these individual location specification records 202 are saved on the user's hard drhre or In a password 
secured directory on the web server 140. When the user wants to generate a new list for one or more of these 

15 records, they simple dick on the specification record. This brings up three options: edit count or process without 
count approval. The edit option provides the user with a way to modify the specifications of a record as desaibed 
above in conjunction with databases 210irecord 202, and save the new specifications. The "count* option performs 
the functions as described above in conjunction with databases 220|Iist 204 and databases 230/Iist 206 and then 
provides the option to perform the operations associated with databases 240 to build the final list 208. The "process 

20 without count approval" option preferably performs all the functions described above in conjunction with databases 
220/list 204, databases 230/list 206 and databases 240/list 208 without prompting the user for count acceptance at 
the end of generating the intermediate list 206. Since the lists are not being processed at the user's input device, the 
user can select the "process without count approval' option on one location list specification record and then 
immediately click on another location specification record. This process is repeated until an desired location 

25 specification records have been submitted for final list processing. 

Referring to Figure 3, a high-level block diagram of the process flow components of the present invention will 
be described. The process flow components may be implemented using the configuration of hardware and software 
elements described in conjunction with Figure 1. State 302 represents the start of a process 300 for specifying and 
building a contact list in real-time with Interaction from a user. Process 300 does not show or mention any billing 

30 mechanism. Since there are numerous methods described in the current art for billing on an account or via a credit 
card, these methods will not be described here, as the current invention does not require a novel method of billing. 

State 304 represents a specification and initialization procedure. This procedure involves specifying the list 
requirements in ternts of geography, data and product scores to be screened on and appended, output formatting and 
delivery methods. This procedure of state 304 also sets the initial list count to zero. 
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State 306 is an extension of state 304 and one skilled in the art could convert these to a single state by 
combining states 304 and 306. State 304 relates more to a user-friendly interface specification while state 306 acts 
as a translator layer between the user and a computer interface. It takes the specifications in state 304 and the 
user's real-time computer accessible files to edit and convert the user specifications into a standard set of computer 
5 application parameters. 

State 308 reads a record from the list databases 230. State 310 tests to see if this is the last record that 
needs to be read from databases 230. This decision state could include a simple end of file test or a maximum test 
record value to search as determined in the select and append process for generating the raw list 206. If decision 
state 310 determines the last record has been read, then process 300 continues with step 320, or else it goes to a 

10 decision state 312. Decision state 312 uses the specifications from state 306 to determine if the record passes or 
fails the various selection tests also defined in state 308. If decision state 312 fails, then process 300 returns to 
state 308 and reads the next record, or else if the decision state 312 passes, process 300 continues to state 314. At 
state 314, process 300 writes an intermediate record containing the data defin^ in state 308. Next, process 300 
continues to state 316 and adds one to the passing record count. Upon completing this task, process 300 returns to 

1 5 state 308 to read the next record from databases 230. 

State 320 indicates that ail required records from databases 230 have been read. Process 300 displays the 
total count of passing records and other optional informatioa such as count by record type and costs to the user. 
Next process 300 proceeds to a decision state 322 where the user utilizes the information provided in state 320 to 
determine if they want to accept the list or not. If the list is not accepted by the user at decision state 322, then 

20 process 300 returns to state 304 and asks for a new set of user specifications. If the list is accepted by the user at 
decision state 322, process 300 moves to a process 330 to lookup and build the contact, e.g., name and address, 
component of the output record. When computers become faster with larga amounts of memory than the computers 
available today, one skilled in the art could eliminate process 330 by keeping the contact items such as name and 
address in databases 230 and writing the data out in state 314, thus eliminating the need to build the name and 

25 address in process 330. Upon completion of process 330, process 300 advances to state 332. 

State 332 transmits the final list to location(s) specified by the user in state 304, such as a client machine or 
node, and/or to a fulfillment organization. The methods of moving data from one machine to another in a network are 
well known in the current art and the current invention does not require a novel method of performing this task. Upon 
completion of state 332, process 300 has completed the task of specifying and building a single contact list in real- 

30 time. The recipient of the final contact list may transmit or broadcast/multicast, in real-time, a message to electronic 
addresses listed in the final contact list. The message may be an e-mail message optionally containing a link to a web 
site on the Internet, for example. The recipient may be restricted to one of various usage levels for the contact list, 
such as read-only usage, one-time usage, or unlimited usage, which may be dependent on user billing. 
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Upon completion of state 332, process 300 moves to a decision state 334 to see if the user desires to 
specify and build anotfier list. If the user answers yes, then process 300 returns to state 304 to begin again, or else if 
the user answers no, process 300 completes at an end state 336. 

Referring to Figure 4, a mid-level block diagram 400 of the general implementation of database and process 
5 components will be described. Figure 4 shows a more specific implementation than shown in Rgure 2. For simplicity 
of user understanding and to provide a user the ability to anonymously specify a custom list and see the cost before 
actually identifying themselves and purchasing, Rgure 4 is divided into four process modules. The modules include 
software that may perform a process, function, subroutine, calculation, procedure, steps executed by a computer, and 
so forth. The four modules are one exemplary way to partition the process flow of Figure 3. 

10 The first processing module is a User Specification Process module 450. Process module 450 provides a 

user with a simple and easy to use user interface that allows them to specify their list requirements. The data 
required for this specification is stored in the network databases 210 and the final set of specifications are written to 
the List Specification Record 202. 

In one embodiment, the geography component of the specification for custom geographies, like radii around 

15 an address, intersection, or landmark and custom defined polygon areas (such as by using latitude and longitude 
vertices), may be defined by a mapping user interface that works over a network. A preferred mapping interface Is the 
MapQuest mapping client/server software API that uses current GOT street and boundary files and QMS address 
standardization software. Standard geographies like ZIP codes. Counties, Cities, and so forth may either be selected 
from a map or from a named list either indhridually or as a group. For example, one could select the entire U.S. as a 

20 geography by selecting either Counties or ZIP codes, and could select all counties or ZIP codes by simply clicking on a 
"select air option. A source for the geography named lists is Claritas Corporation. 

A source for the product scores data component of the specification is also Claritas Corporation. Claritas 
currently provides MicroVision product scores for over 2000 products and services. Claritas can also build custom 
products and service MicroVision geo-demographic profiles using customer data. For easy specification, the profiles 

25 are grouped into meaningful categories, sub-categories and then into individual product or service profiles. 

A source for the consumer demographic portion of the specification is ACXIQM Corporation. ACXIOM 
maintains a household and individual record database that contains demographic variables like presence of child or 
various ages, estimated household income, own or rent, length of time at address, etc. as well as individual 
characteristics like date of birth, gender and marital status, etc. A source of business and government demographic 

30 data Is Claritas. Their Business Facts product has SIC, SOC distributions, number of employees and sales volumes for 
about 10 million business locations. 

A second processing module is a Geography List Build Process module 460. Process module 460 reads the 
geographic segment portion of specification record 202 and uses the equivalency files 420 to create a List of Selected 
Search Geography Codes 404. A pre-existing geography code system is the Zip code system, which has several 

35 components or levels of hierarchy. Thus, the List of Selected Search Geography Codes 404 may be a Zip code list. 
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There are two sources for the equivalency flies that are geography dependent. For geographies that are contained in 
the USPS City/State file and/or the USPS ZIP +4 flies, the USPS is a source of raw data from which the equivalency 
files 420 for these geographies can be built. For all other geographies, Claritas has created flies in this format. 
Databases 220/list 204 in Figure 2 are functionally siniilar to databases 420flist 404 in Figure 4. Therefore, the 
5 Information related to these databases/lists In the description of Figure 2 also applies here. 

A third processing module is the Individual List Sdect and Data Append Process module 470. Process 
module 470 does the following: 

(1) Reads the List Specification Record 202 and the List of Selected Geography 
Codes 404 (e.g.. Zip list) and determines which detailed databases 430 are required to fulfil the list 

1 0 requirements specified In Specification Record 202. 

(2) Loops through the list of ZIP codes In the ZIP List 404 and for each ZIP code, 
reads in parallel all the records within the current ZIP code In the required detailed databases to 
determine which records pass all the specified screening criteria. Then retrieves or calculates all 
specified Items to be appended, writes out an Intermediate Selected Rawllst record to fUe 206/406 

1 5 and Increments the Ust record counters. 

Upon completion of the two tasks above, the process module 470 presents contact list characteristics to the 
user, which In one embodiment include the list sp»af ication, the record counts and the costs of the specified list. The 
process module 470 then provides the option to »ther continue and purchase the list, or discard the current list and 
return to the specification module 450 and re-specify the list. In one embodiment, the user approves all the 

20 characteristics of the current list before purchasing the list although the user can purchase the list by approving one 
or more or a set of the characteristics, if so desired. 

In temns of databases 430, there are multiple database types. A name and address pointer list database is a 
multi-source PrecisionLlst.com compiled database. GOT is a source of a ZIP +4 to Latitude/Longitude (Lat/Lon) file. 
Claritas is a source for a Geo Oemographic Directory for a Geo Demographic system (known as MicroVislon) with its 

25 product profiles tables. ACXIOM Is a consumer household and individual demographics database provider. Claritas is a 
business and government location demographics database provider. A ZIP Index database is built by PrecislonLlst.com 
from the individual databases listed above. Databases 230flist 206 in Figure 2 are functionally similar to databases 
430/list 406 in Rgure 4. Therefore, the Information related to these databases/lists in the description of Rgure 2 also 
applies here. 

30 The fourth and last processing module in Rgure 4 is the Contact Item Lookup Process module 480. In one 

embodiment, the process module 480 does the following: 

(1) Reads the records in the Intermediate Raw List 406, looks up the corresponding 
names and addresses (or other Items in other embodiments) In database 440, formats the output 
record according to the specifications In record 202 and writes the final formatted output record to 
35 the Final Ust file 408. 



.16- 



wo 02/29675 



PCTAJSOl/30863 



(2) Upon completing the Final List file 408. process module 480 either delivers file 
408 to the location specified in record 202 or notifies the user and/or third party as to where to 
obtain (e.g.« download) the file 408. 

A source of the ZlP-i-4 Coding Guide and the ZIP to City/State tables is the USPS. A source of the Name 
5 files is the 1990 Census Name files that have been enhanced with names from the National business and consumer 
White pages provided by ACXIOM. Databases 240/list 208 in Figure 2 are functionally similar to databases 440/list 
408 in Rpre 4. Therefore, the information related to these databases/list in the description of Figure 2 also applies 
here. 

Referring to Figure 5, an implementation of the database and process components 500 of the present 
10 invention that are used to build a Final List file 208/408 will be described. Process 450 comprises two component 
modules: 512 and 514. 

Module 512 represents the process of specifying all the non-geography requirements for a direct marketing 
list. This involves several components that fall into four primary categories: screening/selecting, appending, formatting 
and delivery specification. 

15 These components are described in general terms in conjunction with Figure 2. The description 

corresponding with Figure 2 also presents a host of altemative implementations. The following description of Rgure 5 
revolves around using MicroVision geo-demographic data as a specific example for scoring, selecting on and/or 
appending specific product scoring consumption data to a list record. One skilled in the art could easily substitute a 
regression method or some other type of individual household, business or small geography real-time segmentation 

20 scoring system. 

Module 512 starts by displaying a list of products/services from which the user can select to either screen 
on or append. These products/services have supporting profiles stored in databases 502a, 502b, 502c ... to 502n, 
etc., where information corresponding to one product/service is stored per database, in one embodiment. Presently, 
with MicroVision there are current profiles for over 2,000 products and services. In one embodiment, as shown in the 

25 databases 502. each of these profiles is stored in a MicroVision Profile (MVP) file that contains, for each of the fifty 
MicroVision segments, a segment number, base count, sample count and a consumption value. Other embodiments 
may have a different number of segments, for example. Not all profiles have a consumption value. 

A segment is a group, where members of the same group are similar in terms of age, income, race, housing 
type and other social/economic characteristics. In terms of these group identification factors, the variation in 

30 characteristics between groups is much greater than the variation within groups. This intra-group consistency and 
inter-group variation is what makes segmentation systems discriminate across a variety of product and service usage 
and consumption patterns. In terms of a national, randomly distributed consumer panel of say 50,000 members, each 
of the panel members is classified into a single segment. The total count of panel members by segment is termed the 
base count. For a specific product, like current owners of a Certificate of Deposit (CO), the total by segment of 
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members owning a CO is termed the sample count, white the average dollar amount of CD's owned per sample 
segment member is termed the segment consumption value. 

Using at least one of the base count, sample count and consumption value as input there are several 
different methods or equations that may be used to calculate a segment score. One equation for determining a score 
5 or index, the segment index score, is described below. 

An indhridual segment index score (relathre to an average score of 100) is determined by dividing the sample 
segment proportion by the base segment proportion and multiplying the result by one hundred. Both the base and 
sample segment proportions are determined by summing the segment counts independently for both the base and 
sample columns to get a total base and sample count. The sample and base segment proportions are then detemrtined 

10 by dividing the individual segments counts in each cohimn by their respective cohimn total count. The score from this 
method results in an index based around 100, where 100 is average, while a segment score that is 200 is twice the 
average. The segment scores for the selected product(s) are stored in a product score table 504. Table 504 shows 
only a single product/service score for simplicity of Hhjstration. However, multiple or a weighted combination of 
product scares could easily be supported. 

15 One embodinmt utilizes the MicroVision Geodemographic system. The Claritas Infomark User's Guide and 

Reference Manuals describe the MicroVision segments, base counts, sample counts, and consumption values in detail 
for various panel data sets. The Guide and Manuals also descnlie the various equations or methods that can be used 
to perform various mathematical computations of these values to generate various types of segment scores and 
indices. There are many other types of non-geography selects and appends and other spedfications, like output 

20 formats and location, that are supported by module 512 and are well known in the direct marketing industry. 
Additional data that is available for selecting and appending b listed in a demographic attribute dictionary, which is a 
database 503. Most of these other types of general demographic selects and appends were previously described in 
the general description of Rgure 2 and will not be described again here. 

Module 514 is the geography analog of module 512. Module 514 provides a way of defining a geography 

25 from which the list is to be extracted. There are basically two ways to specify geography at module 514: (1) via a 
spatial definition like a radius around an address/intersection or an irregular shaped polygon defined by coordinate 
vertices or (2) via a geography code or geography name. In one embodiment, a map is a basic requirement in order to 
easily define and validate geographies spatially. It is possible to accomplish this task without a map, but it may be 
much more difficult and may be prone to several types of errors. One embodiment uses mapping server software from 

30 MapQuest with underlying cartographic databases 506 and software from GOT and QMS. This software and the 
underlying databases 506 provide the tools to design a basic user interface that provides a way for a usm to provide, 
e.g., type in, an address/intersection/landmark and see it plotted on a detailed street map. The user can then either 
define a radius or digitize a polygon service area around this visually verified point. It is also desirable to spatially 
define the following using a mapping interface: rings, quadrants, multiple non contiguous polygons, polygons with holes 
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or donuts, as well as definitions, like corridors, e.g., all records within D.25 miles of a highway between points A and 
B. 

Geography specification or definition in module 514 using codes and names is done using a geography name 
database 508, which contains a list of geography names and/or codes. Optionally, using the map database 506, a 
5 browser window may display these geographic areas as polygons with labels. In most cases, the list is preferred, as 
most people know the geography name they want, like San Diego, or the code, like zip code 92130. Module 514 
provides the ability to select multiple geographies, like five zip codes, or geographies of different types, like a county 
plus two zip codes. It is also provides the ability to define a geography where a user specifies a geography, like a 
county but excluding two specific zip codes. 

10 Upon completing both modules 512 and 514, process 500 proceeds to write the specification record 202. In 

one embodiment, this record contains all the user specifications for the list. There are numerous ways to store this 
information in the specification record 202. It is also possible to store these specifications in memory and not 
physically write out a file. If the records are not at some point written to disk, then the multi-unit retailer option 
described in conjunction with Figure 2 may not be possible. 

15 Next process 500 continues at process 460 and reads the list specification record 202. In one embodiment, 

process 460 builds a list of 5-digit zip codes to be searched. One embodiment for doing this utilizes geography (e.g., 
zip) ^uivalency files 516 to 526. The geography etiuivalency fOes may include a Zip file 516, a Lat/Lon Windows file 
518, a DMA file 520, a MSA file 522, a StatelCounty file 524. and a City file 526. In general, each of these 
equivalency files has a set of records, where each record has a code or an identifier field and a 5-digit zip code field, for 

20 example. The zip file 516 has a 5-digit zip code and a 5-digit zip code, or a 5-digit zip code name like San Diego, CA 
and a 5-digit zip code. This file provides a way to specify zip codes using a one to one equivalency file without having 
to create a different form of specification for a ZIP Code geography list. This is also the preferred selection method 
for having the geography be the entire United States, which is done by pressing the "select all" option after selecting 
the ZIP code geography list. 

25 In one embodiment, the 5-digit zip code is the base geography because it is the native geography for the 

mailing industry. Based on the geography codes or spatial definitions read from record 202, process 460 reads the 
appropriate equivalency files and builds an intermediate list of all 5-digit zip codes satisfying the geography codes or 
spatial definitions. Before writing this list to a zip list file 404, process 460 orders the list in S digit zip code order and 
removes duplicate entries from the list. The spatially defined geographies, e.g., radii and polygons, use a special 

30 equivalence file called the latitude and longitude zip windows file 518. The building of this zip windows file and the 
technique for determining which windows are overiapped by a spatially defined geography are described in detail in 
Applicant's issued patent, U.S. Patent No. 5,958,397. 

At the completion of building the zip list file 404, process 500 proceeds to process 470, which builds an 
intermediate list or file 206f406 of all selected records and provides counts (e.g., the total number of selected records) 

35 to the user. Process 470 first reads the list specification record 202 and the zip list file 404. If a product/service 
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profile is specified, process 470 reads the specified product/service profile database 502 and builds a product scores 
table 504 for the specified product/service, as described above. Next, process 470 begins to loop through the zip 
codes read from zip list 404. For each zip in the zip list process 470 looks up the zip pointers in a geography (e.g.. zip) 
index table 530 for the start of the zip code data in databases 540 to 546 which have data stored in zip code order. 

5 In one embodiment, the zip index table 530 may have a set of records having a S-digit zip field, a 

Demographic Attributes pointer field, a List pointer field, a Lat/Lon pointer field and a Geo-Demographic (GD) pointer 
field. A Geo-Demographic Directory 540 may have a set of records having the following fields: Zip +4, Segment ft, 
and Demographic Data. A Geography (e.g., Zip'»-4) to Spatial Coordinate (e.g., Lat/Lon) Database 542 may have a set 
of records having the following fields: Zip+4, Latitude, Longitude, and Flags. A List Database 544 nray have a set of 

10 records having the following fields: Zip+6, Last Name Code, First Name Code, Middle Initial Code, and Flags. A 
Demographic Attributes Database 546 may have a set of records having the following fields: Zip +6, Age, Children, 
and Own/Rent. 

Process 470 then advances to the starting or first 5-digit zip (ZIP5) pointer location as illustrated by lines 
538 to 532 for each of the databases 540 to 546. Using the list database 544 as the driver database, process 470 

15 sequentially reads the other databases 540, 542 and 546 always maintaining a matching key relationship with 
database 544. In one embodiment, for each record in database 544, process 470 uses the matching key records in the 
other databases to perform all the screening criteria 6.e., detemiines if the record spatially lies within the defined 
polygon and has a product score for a product X above the selected saeening value). If a record from database 544 
passes all screening aiteria, the record and the specified append data are written to the selected raw list file 206/406 

20 and the selected record counts are incremented. If the record does not pass all the screening criteria, it is not written 
to file 206/406 and the counts are not increments. 

After completing the processing described above related to a record in database 544, process 470 proceeds 
to the next record on database 544 and tests the key against the current ZIP5. If the key is in the same ZIPS, it 
processes the record as above. This process is repeated until all records in the current ZIPS in database 544 have 

25 been processed. When a record in database 544 with a new ZIPS is read, process 470 falls back to the ZIPS loop and 
reads the next ZIPS in the Zip list 404. Each zip in the Zip list 404 is processed in the above manner until all zips in the 
Zip list 404 have been read. After processing all ZIPSs in Zip list 404, process 470 has counts that it can present to 
the user and has completed generating the selected raw list file 206/406. If the user does not approve the counts, 
process 500 returns to the process module 450 to start over. On the other hand, if the user approves the counts, 

30 process 500 moves to the process module 480. 

Process 480 sequentially reads the Selected Raw List file 206/406 and builds a Final List file 208/408 that 
contains names and addresses in the fonnat specified in the List Specification record 202. Process 480 is a specific 
embodiment of process 330 (Figure 3). The name fields in the Final List record 208/408 are populated by retrieving the 
first 572, middle 574 and last name 576 table records corresponding to the first, middle and last name codes of the 

35 Selected Raw List record 206/406 in the corresponding First 572, Middle 574 and Last Name 576 databases. 
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The address fields in Final List 208f408 are populated by process 480 in a manner similar to that used for 
the name fields. However, the address construction requires a few more tables and a tittle more complex logic. In 
general terms, process 480 uses an address coding guide such as a ZIP +4 Address database 570 in conjunction with a 
collection of individual address component databases 552 to construct the first address line of a mailing address. The 
5 collection of databases 552 includes a Street Name database 554, a Street Address Range database 556, a Street 
Type database 558, a Street Direction database 560, a Secondary Address Type database 562, and a Secondary 
Address Range database 564. In one embodiment the databases 554, 556, 558 and 560 each include a plurality of 
records having a code field and a field corresponding to the name of the database. First, process 480 uses the ZIP +4 
portion of the ZIP+4 key in the Raw List file 206/406 to look up the base record for the ZIP+4 in the ZlP-t-4 Address 

10 database 570 and retrieve the ZIP-»-4 type. In one embodiment, there are six ZIP+4 address types: street, high-rise, 
firm, rural route, PO Box and General delivery. The rules for constructing the first line address vary slightly based on 
the address type. The rules for constructing the most common ZIP-t-4 address type, i.e., the street addresses, are 
explained in detail below. Given the street example, one skilled in the technology would apply the method and the rules 
for constructing the other address types. 

15 The general method used by process 480 to construct the priniary address or building number portion of a 

street address is as follows. A street range code from database 570 is used to retrieve the low street range value 
from the street range database 556. A str^ address range in database 556 typically has a high street range value 
and a low street range value that only differs in the last two digits, l.e., 4301 to 4399. Next, the last two digits of 
the ZIP'*'6 from the Raw List file 206/406 are used to replace the last two digits of the retrieved str^t range low 

20 value. Process 480 determines the street name portion of the address by using the name code from the Zip't-4 
Address database 570 to retrieve the street name from the Street Name database 554. Process 480 uses this same 
process to retrieve the street type from the Street Type database 558, and the street pre and post directions from the 
Street Oirection database 560. At this point, process 480 has assembled all the components required to format the 
first line of a street address as specified in the List Specification record 202. High-rise and firm address type records 

25 require process 480 to use similar logic and access the Secondary Address Type database 562 and the Secondary 
Address Range database 564 to construct a secondary address, such as "APT 4A'. 

Next, process 480 uses the 5-digit zip code portion of the ZIP +6 in the Selected Raw List file 206/406 to 
retrieve the USPS preferred city and state associated with the 5 digit zip code from a City/State database 578. Once 
process 480 has completed constructing the name and address for each record, it writes a record to the Final List file 

30 208/408 that corresponds to the specification in the List Specification record 202. Once process 480 has read all 
records from the Selected Raw List file 206/406. constructed the name and address, refomnatted the records 
according to the specifications from Specification record 202 and written the last record to file 208/408, the process 
500 illustrated by Figure 5 has completed its task of creating the Final List file 208/408. 
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Referring to Figure 6, one embodiment of a list specification and creation process 600 will be described. 
Process 600 is one specific implementation of process 300 (Rgure 3h and may be performed by the modules 450. 
460,470 and 480 (Figure 4). 

Process 600 starts at state 602 and proceeds to state 604 where the process allows the user to select a 
5 product or service profile from a list of profiles. State 604 also prompts the user to select a consumption calculation 
method or equation from a list of methods, a profile score screening (threshold) value and whether the score is to be 
appended to the selected list or only to be used for screening. An example of a specific equation calculation method 
was previously described in the previous discussion related to Figure 5. The sample equation described in conjunction 
with Figure 5 did not use any consumption data. For consumption data, one of the equations is for the sample base 

10 consumption value, which is a value stored in the MVP files and is the average consumption value for members of the 
segment that consume the product or service. Another ^uation is for the base consumption vahie, which is the 
santple consumption value multiplied by the ratio of the sample count over the base count. The base consumption 
value provides an expected consumption amount by segment that includes both segment member product users and 
non-users. Both the sample and base segm^t consumption amounts may be transformed into index values by simply 

15 dividing the segment sample and base consumption values by the total sample and base consumption values and 
multiplying by 100. For the preferred Geodemographic system, MicroVision, the Clarhas Infomark User's Guide and 
Reference Manuals describe in detail the various equations or methods that can be used to perform various 
mathematical computations to generate various types of segment scores and indices. In addition, these manuals 
discuss the advantages and disadvantages of the various equations for different applications and products. Next, 

20 state 604 prompts the user to select from a list of other screening and append data items and values. After the user 
has completed the screening and data append selections, state 604 initializes the selected record count to zero and 
proceeds to a decision state 606. 

Decision state 606 prompts the user to select either a standard geography or a custom geography (e.g., 
radius or polygon). If the user selects standard geography, process 600 proceeds to state 608. State 608 first 

25 presents to the user a list of geography types like ZIP, City, County, etc. and the user selects a geography type. Once 
the user has selected a geography type, state 608 presents to the user a list of geographies of this selected type. The 
user then selects the geographies to which they desire to notify, mail or market. After completing the geography 
selections at state 608, process 600 moves to state 610. State 610 looks up the selected geographies on the 
appropriate geography to zip code equivalency file (files 516-526) and generates a deduplicated (deduped) and ordered 

30 list of zip codes 404 [Figure 5) that are geographically equhralent to the selected standard geographies. Upon 
completing state 610, process 600 proceeds to state 616. 

Returning to state 606, if the user selected a custom geography, process 600 moves to a process 612 that 
generates a list of lat/lon defined windows. The process 612 is further described in conjunction with Figure 7. In one 
embodiment, the tat/Ion defined windows are approximate six mile square windows that have an individual 

35 identification code determined by the process 612 desaibed in Figure 7, and spatially overiap the radii or polygon area 
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described in Figure 7. Once the list of lat/lon windows has been determined by process 612, process 600 proceeds to 
state 614, which is similar to state 610 for standard geographies. State 614 uses the list of lat/lon windows from 
process 612 and generates a deduped and ordered list of zip codes 404 that potentially spatially overlap the custom 
geography area. Upon completing state 614, process 600 proceeds to state 616. 
5 At state 616, process 600 reads the selected profile record and, based on the method or equation, computes 

a score for each of the individual segments. Examples related to various equations and calculation methods for 
determining a segment score were previously described in conjunction with Figure 5 and Figure 6 above. There are 50 
segments in one implementation using MicroVision. These 50 scores corresponding to the 50 segments are loaded into 
a mrnnory table with 50 cells, where the score for segment 1 is stored in cell 1 and the score for segment 2 is stored 

1 0 in cell 2, etc After completing state 6 1 6, process 600 proceeds to a Screen and Build Raw List process 620. 

Process 620 is described in general terms here and is further described in conjunction with Figure 8. Process 
620 may be a specific embodiment of process 470 (Figure 4). Process 620 uses the Geography Code (e.g.. Zip) List 
404 (Figure 5) as a source, and for each zip code in the list, uses the pointers in the Zip index 530 (Figure 5) to read the 
first record for the current Zip in the detail files, Le., the List Database 544, the Geo-OOTiographic Directory 540, the 

15 ZIP +4 to LatlLon Database 542 and the Demographic Attributes Database 546. Using the information for the List 
Specification Record 202 (Rgure 5), process 620 reads each record for the current Zip from the List Database 544 and 
matching records from the other three databases 540, 542 and 546, and determines whether the record has passed ail 
the screening criteria. If the record fails any test, it is not written to the Selected Raw List file 206/406 (Figure 5), 
while passing records are formatted according to the specifications in the List Specification Record 202 and written to 

20 the Selected Raw List file 206/406. Regardless of pass or fail, process 620 then proceeds to read the next record in 
the List Database 544 and repeats the process outlined above until a Zip is encountered in the List Database 544 that 
is different than the current ZIP on Zip List 404. Process 620 then moves to the next ZIP and performs the above 
procedure until all Zips on Zip List 404 have been processed. 

After completing process 620 as described above, where process 620 has read and tested all candidate 

25 records within the geographic areas specified at state 604, as well as counted the records that passed all screening 
criteria, process 600 then advances to state 622. State 622 presents this count of records to the user and then 
process 600 moves to a decision state 624 to get the user's response as to whether the count is acceptable. If the 
user rejects the count, process 600 moves back to state 604. The user may reject the count, for example, because 
the count exceeds the number of pieces that the user has had printed for the mailing. If the user accepts the count, as 

30 determined at the decision state 624, process 600 moves to a process 330. 

Process 330 is generally described here and is further described in conjunction with Figure 9. In one 
embodiment, process 330 sequentially reads each record in the Intemiediate list 206/406 and uses the pointers in this 
list to retrieve the appropriate name stored in the Name tables 572, 574 and 576 (Figure 5) preferably stored in 
memory to retrieve a full name. Process 330 then uses the full ZIP<i>6 or delivery point code (DPC) from the Raw list 

35 206/406 to construct the street portion of a mailing address by accessing tables 570 and 552 preferably stored in 
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meinory. Finally, process 330 uses the S-digit Zip Code portion of the ZIP +6 from the Raw List 206/406 to access 
the City/State database 578 to build the City and State portion of the mailing address. Upon completion of building 
the name and address, process 330 writes the formatted final record to the Final List file 208/408. 

After process 330 operates on all records in the Intermediate list 206/406, process 600 moves to state 628. 
5 At state 628, process 600 downloads the Final List file 208/406 to a specified network address such as a user- 
specified node. This user* specified node nnay be the same node as the user specification node for generating the list 
specification, or the nodes may be different nodes. In another embodiment, other ways of delhrering the file are 
envisioned. Process 600 then proceeds to decision state 630 and inquires if the user wants to specify another list. If 
the user responds with 'yes,* then process 600 returns to state 604 to begin process 600 again, otherwise if the user 

10 responds with "no," process 600 advances to an end state 632. 

Referring to Figure 1, one ortbodiment of radius and polygon definition components of the present invention 
as used in the process 612 will be described. Process 612 is directed to specifying the radius and polygon definition 
requirements for a direct marketing list using mapping tools. Process 612 begins at a start state 702 and provides the 
user with a mapping interface. In one embodim^t, mapping software for use over a network is mapping software 

IS such as available from MapOuest™. Process 612 then proceeds to state 704 where the mapping software prompts 
the user for a location identifier. The location identifier can be any identifier where there is a way available for 
translating the identifier to a latitude and longitude coordinate. Examples of identifiers are a phone number, an 
address, an intersection, a DPC code, latitude and longitude coordinates, or a landmark name like Yankee stadium. 
Once the user has provided a location identifier at state 704, process 612 moves to state 706 where, in one 

20 embodiment, the mapping software translates the location identifier to a latitude and longitude and displays a map 
around the user-specified location. The user may zoom in or out until the correct map scale is displayed. After the 
user has visually verified that the location is correct, process 612 moves to state 708 and asks the user to enter a 
radius or to draw a polygon trade area on the map. If the user identified a polygon trade area on the map, state 708 
digitizes the trade area by, in one embodiment identifying and clicking on the map screen location of the vertices of 

25 the trade area using the left mouse button. At the completion of state 708, process 612 moves to state 710. 

At state 710, process 612 determines the latitude and longitude extremes of the user's custom defined area 
and then moves to state 712. In one embodiment, state 712 uses the extremes to build a deduplicated and ordered list 
of one-tenth of a degree rectangular latitude and longitude spatial windows that spatially overlap the user-defined 
area. The processing performed at states 710 and 712 is described in Applicant's U.S. Patent No. 5,956,397. Upon 

30 completing state 7 1 2, process 6 1 2 moves to a return state 7 1 4 and returns to process 600 (Figure 6). 

Referring to Rgure 8 (and Figure 5), one embodiment of process 620 for reading records within selected ZIP 
codes contained in the ZIP List 404 from databases 540, 542, 544 and 546, performing a screening function on each 
read record based on specifications defined in the List Specification Record 202, and counting and writing passing 
records to the Selected Raw List file 206/406 will be described. A preferred implementation of Rgure 8 includes 

35 preprocessing on the databases 540, 542, 544 and 546. so that database 540, 542 and 546 do not contain a 
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matching key record that is not on database 544. Additionally, the databases 540, 542. 544 and 546 are sorted by a 
match key in descending order. This off-line preprocessing may be done in order to improve real-time processing 
pert omiance for this list generation application. 

Process 620 begins at start state 802, moves to state 804 to read a record on the Zip List 404 and proceeds 
5 to a decision state 806. Decision state 806 tests to see if all records have been read from the Zip List 404. If all 
records have been read, process 620 proceeds to a return state 808 and returns to process 600 (Figure 6). Otherwise, 
process 620 advances to state 810 and reads the current ZIP rrcord in the Zip Index File 530 to get the file offset 
pointers for this ZIP code into each of the four detailed databases 540, 542, 544 and 546, so that it can read the first 
record in this ZIP code from each of the databases. In one embodiment, the following three-step process is identical 

10 for all four databases and each will be described individually below. For the Geo-Demographic database 540, process 
620 proceeds to state 812 and gets the current zip file offset pointer for the Geo-demographic database 540. Process 
620 then moves to state 814 where it advances to the offset pointer position in the Geo-Demographic Database 540 
and moves to state 816 where it reads the first record in the current ZIP code in the Geo-Demographic Database 540. 
In parallel to state 812, process 620 process to state 822 where it gets the current zip file offset pointer for the 

15 ZIP 4- 4 to Lat/Lon Database 542. Process 620 then moves to state 824 whore it advances to the offset pointer 
position in the ZIP+4 to Lat/Lon Database 542 and moves to state 826 where it reads the first record in the current 
ZIP code in the ZtP+4 to Lat/Lon Database 542. In parallel to states 812 and 822, process 620 proceeds to state 
832 where it gets the current zip file offset pointer for the List Database 544. Process 620 then moves to state 834 
where it advances to the offset pointer position in the List Database 544 and moves to state 836 where it reads the 

20 first record in the current ZIP code in the List Database 544. In parallel to states 812, 822 and 832, process 620 
proceeds to state 842 where it gets the current zip file offset pointer for the Demographic Database 546. Process 
620 then moves to state 844 where it advances to the offset points position in the Demographic Database 546 and 
moves to state 846 where it reads the first record in the current ZIP code in the Demographic Database 546. In one 
embodiment, the groups of states 812-816, 822-826, 832-836 and 842-846 may each be executed by a separate 

25 thread in an operating system capable of multithreaded operation, e.g., Windows NT and Unix. After reading the first 
record in the current ZIP for all four detaned record databases 540, 542, 544 and 546, process 620 moves to a 
Database Synchronization process 850. 

The Database Synchronization process 850 ensures that the current in-memory match keys for the 
supporting databases 540, 542 and 546 with their associated data items all match the current match key associated 

30 with the List Database 544, which is the drhrer database. Process 850 will be further described in conjunction with 
Figure 10. At the point process 850 has synchronized the match keys in all four databases, process 620 proceeds to a 
Record Screening process 860. The process 860 uses the inf onnation associated with the current record from the 
detailed databases 540, 542, 544 and 546 and performs spatial, product score and other screening tests as defined in 
the List Specification Record 202. Process 860 will be further desaibed in conjunction with Figure 1 1. At the point a 
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detail record fails any test in process 860, process 620 moves to state 868. If a record passes all tests in process 
860, process 620 advances to state 862. 

At state 862, process 620 uses the specifications defined in the List Specification Record 202 in conjunction 
with the detailed data from the current record in the detailed record databases 540, 542, 544 and 546 to build a 
5 m^ory version of the raw selected record. After building the memory version of the raw record in state 862, process 
620 moves to state 864 where it writes the raw record to disk or other form of mass storage. Next, process 620 
advances to state 866 where it adds one to the selected record count. Process 620 then moves to state 868 where it 
reads the next record from the List Database 544. Process 620 then proceeds to a decision state 870. If decision 
state 870 determines that the zip code of the record just read from database 544 is different than the current Zip in 

10 the ZIP List 404, then process 620 returns to state 804 to read the ZIP List. If the last record read from the Ust 
Database 544 matches the current ZIP code from the ZIP List 404, then decision state 870 directs process 620 to 
move back to the Synchronize Database process 850. 

Referring to Rgure 9 (and Rgure 5), one ranbodiment of process 330 building the name and address record 
components of the present invention will be descn'bed. In other embodiments, other contact record components are 

1 5 built. Process 330 reads all the records of the Int^ediate file (Selected Raw list) 206/406, and uses the pointers in 
these records to lookup artd build a hjll name and address. Process 330 may also re-format the record and write out a 
final record that is formatted to user specifications and contains a full name and address, in one embodinient. 

Process 330 begins at start state 902 and proceeds to state 904 where it reads a record from the 
Intermediate list 206/406 and moves to state 906 to build contact components. For example, at state 906, process 

20 330 uses the ZIP+B from the read record of the list 206/406 in conjunction with menrary resident database files 570, 
552 and 578 that were created from the USPS ZIP-t-4 and the City/State file so as to build a USPS CASS certified 
address. Upon completing state 908, process 330 moves to state 908. At state 908, process 330 uses the first 
middle and last name pointers from the Intermediate file 206/406 to lookup the first name in mennory table 572, the 
middle initial in mmiory table 574 and the last name in memory table 576. Process 330 then moves to state 910 and 

25 takes the address derived at state 906, the name derived at state 908 and other data from the current record of the 
Intermediate file 206/406, and creates a new formatted record, which is written to the Final List file 208/408. After 
writing the record, process 330 moves to a decision state 912. If decision state 912 detemtines that there are still 
remaining records to process on Intermediate list 206/406, then process 330 moves back to state 904 to access the 
next record in the list. If all records have been read from the list 206/406, then process 330 moves to a return state 

30 9 1 4 and returns to process 600 (Figure 6). 

Referring to Rgure 10 (and Rgure 5), one embodiment of the Database Synchronization process 850 will be 
described. The Database Synchronization Process 850 ensures that the current in-memory match keys for the 
supporting databases (Geo-Oemographic 540, ZIP'«-4 to Lat/Lon 542 and Demographic 546) with their associated data 
items all match the current match key associated with the List Database 544, which is the dfm database. 
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Process 850 begins at start state 1002 and proceeds to state 1004 and sets current List Database ZIP+4 
and ZIP+6 values as synchronization marks. State 1004 sets the ZIP+4 and ZIP+6 synchronization marks to the 
current value of these two items in the current List Database 544 record. Process 850 then proceeds to a decision 
state 1006 to determine if the current Geo Oemographic Database ZIP-t'4 matches the current synchronized List 
5 Database ZIP'i-4. If the two ZIP+4$ do not match, then process 850 proceeds to state 1008 where it reads the next 
record from the Geo-Demographic Database 540 and moves back to the decision state 1008. If the two ZIP'i-45 
match at decision state 1006, then process 850 proceeds to a decision state 1010 where it compares the current 
synchronized ZIP't-4 to the ZIP-*-4 on the current record from the ZIP+4 to Lat/Lon Database 542. If the two ZIP<i-4s 
do not match, then process 850 proceeds to state 1012 where it reads the next record from the ZIP-t-4 to Lat/Lon 

10 Database 542 and moves back to the decision state 1010. If the two ZIP+4s match at decision state 1D10. th^ 
process 850 proceeds to a decision state 1014 where it compares the current synchronized ZIP+6 to the ZIP+6 on 
the current record of the Demographic Database 546. If the two ZlP+6s do not match, then process 850 proceeds to 
state 1016 where it reads the next record from the Demographic Database 546 and moves back to the decision state 
1014. If the two ZIP+6s match at decision state 1014, then process 850 proceeds to return state 1018 and returns 

1 5 to process 620 (Figure 8). Upon reaching return state 101 8, all three-support databases 540, 542, and 546 have been 
synchronized on their ZIP+4 or ZIP+6 match keys with the List Database 544. 

Referring to Figure 11 {and Figure 5), one embodiment of the Record Screening Process 860 will be 
described. The process 860 utilizes the information associated with the current record from the detailed databases 
540, 542, 544 and 546. and performs spatial, product score and other screening tests as defined in the List 

20 Specification Record 202. 

Process 860 begins at start state 1 102 and moves to state 1 104 to perform geography/spatial tests. One 
embodiment utilizes methods of determining if a record with a specific coordinate, such as a latitude and longitude 
coordinate, is spatially located inside or outside an area of any size or shape that is defined by a point (with 
coordinates) and a radius, or a polygon defined by multiple vertices (each having coordinates), such as described in 

25 detail in Applicant's U.S. Patent No. 5.956,397. Records that pass the above geography/spatial test as being inside 
the desired mailing area are flagged to be passing, while records that fail the test are flagged to be failing. 

In cases where the geography is a standard geography, like a county, then the upstream county to zip code 
equivalency file 524 provides a 99+% geographic solution to this problem. If this level of accuracy is acceptable, then 
all records are flagged as passing the geography/spatial tests 1104. In order to get the remaining less than 1% 

30 accuracy, the system needs to carry a county code on one of the detailed files. The preferred file is this case is the 
GOT ZIP+4 to Lat/Lon file 542 as GOT provides the state and county in which each ZIP+4 is located and ZIP+4s do 
not cross county boundaries. In this case, tests 1104 would have to compare the state and county code on the 
current record to the list of selected state and county codes from the List Specification Record 202. If the current 
record's state and county code is on the List Specification record, then the record is flagged as passing the geography 

35 test, otherwise it is flagged as failing the geography test. 
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After testing and flagging a record as either passing or failing at the geographv/spatial tests 1104, process 
860 moves to a decision state 1 106. If the current record's geography/spatial tests flag is set as failing, process 860 
sets its overall record return flag to fail and moves to a return fait state 1 108 and returns to process 620 (Figure 8). If 
the current record's geography/spatial tests flag is set as passing, process 860 proceeds to state 1 1 10 and determines 

5 a product score. The score for a product scoring method such as MicroVision was previously compute for the product 
selected in the List Specification Record 202 and the score for each of the fifty MicroVision segments is stored in the 
Product Scores table 504. State 1110 uses the MicroVision code values of one to fifty associated with the current 
record that was previously read from the Geo*Demographic Directory Database 540 and looks up this value in the 
Products Scores table 504 to determine the product score for the current record. As previously discussed, there are 

10 other methods for determining a product score that could readily be employed by one skilled in the art, but the method 
described above is preferred because of its speed, simplicity and the large number of products and services that have 
MicroVision profiles. 

After process 860 has determined a product or service score at state 1110, it moves to a decision state 
1 1 12 and tests the determined score against the minimum acceptable score value from the List Specification Record 
1 5 202. If the score determined by state 1 1 10 is less than the minimum score from the List Specification Record 202, 
then process 860 sets the product score flag as failing. If the score determined by state 11 10 is greater than or equal 
to the minimum score from the List Specification Record 202, then process 860 sets the product score flag as passing. 
If no product score screening was selected by the user, state 1112 automatically sets the product score flag as 
passing. 

20 If the product score flag is set as failing at decision state 1112, then process 860 sets its overall record 

return flag to fail and moves to the return fail state 1 108 and returns to process 620 (Rgure 8). If the product score 
flag is set as passing, then process 860 advances to state 1 1 14 to perform other screening tests. The other screening 
criteria specifications, such as name-only records, no P.O. Box or Rural route records, and records with an estimated 
household income over a selected amount (e.g., $50,000), are retrieved from the List Specification Record 202. State 

25 1114 sets the other screening test flag value as passing and then tests the specified screening criteria against the 
corresponding values of the current record. If the current record fails any test, the other screening test flag is set as 
failing. 

Upon performing all other screening tests at state 1 1 14, process 860 proceeds to a decision state 11 16 to 
detemfiine if the current record passes the other screening tests. If the current record's other screening test flag is set 
30 as failing, process 860 sets its overall record return flag to fail and moves to the return fail state 1 108 and returns to 
process 620 (Figure 8). tf the current record's other screening test flag is set as passing, process 860 sets its overall 
record return flag to pass, and moves to a return pass state 1 1 1 8 to return to process 620 (Fipre 8). 
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Specific blocks, sections, devices, functions and modules may have been set forth. However, a skilled 
technologist will realize that there are many ways to partition the system of the present invention, and that there are many 
parts, components, modules or functions that may be substituted for those fisted above. 

While the above detailed description has shown, described, and pointed out the fundamental novel features of 
5 the invention as applied to various embodiments, it will be understood that various omissions and substitutions and 
changes in the form and details of the system illustrated may be made by those skilled in the art without d^arting from 
the intent of the invention. 
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WHATISCUIMEDIS: 

1. A computerized real-time, interactive method of building a list of contact records based on selected 
criteria, the method comprising: 

obtaining a geographic area definition, a classification and a threshold value associated with the 
5 classification; 

generating a search geography code list of geography codes based on the geographic area 
definition; 

determining a selected set of records in a fist database based on the geography codes in the search 
geography code list 

10 identifying a spatial coordinate and a socio economic code corresponding to a sub^eography code 

for each record in the selected set of records; 

identifying a classification score for each record In the selected set of records based on the socio- 
economic code; and 

determining identified records in the select^ set of records based on a comparison of the 
15 classification score with the threshold vahje and if the spatial coordinate associated with the record is 

located within the geographic area definition. 

2. The method defined in Claim 1, additionally comprising providing a contact address corresponding 
to each identified record in the selected set of records If a ndnimum user threshold number of records are identified. 

3. The method defined in Claim 2, additionally comprising transmitting to a user the contact addresses 
20 for the records in the Identified records having contact addresses. 

4. The method defined in Claim 2, additionally comprising providing selected append data 
corresponding to each identified record in the selected set of records. 

5. The method defined in Claim 4, additionally comprising transmining to a user the append data 
corresponding to the identified records having contact addresses. 

25 6. The method defined in Claim 4, wherein the append data includes at least one of the following: 

contact name, classification score, distance, pres&ice of child, age of child, estimated household income, ownership 
status, length of time at address, date of birth, gender, marital status, business name, SIC code, number of employees 
and sales. 

7. The method defined in Claim 4, wherein providing selected append data includes selecting at least 
30 one append data type from a list of displayed append data types. 

8. The method defined in Claim 1, additionally comprising providing a contact name and a secondary 
contact address corresponding to each identified record in the selected set of records if a minimum user threshold 
number of records are identified. 

9. The method defined in Claim 8, wherein the secondary contact address comprises a telephone 

35 number. 

•30- 



wo 02/29675 PCTAJSO 1/30863 

10. The method defined in Claim 1, wherein the list database has a plurality of records and a least one 
record comprises a code and a name code. 

11. The method defined in Claim 1 , wherein the geographic area definition comprises: 
a desired location identifier; and 

5 a radius. 

1 2. The method defined in Claim 1 , wherein the geographic area definition comprises: 
a desired address; and 

a polygon around a location identified by the address. 

13. The method defined in Claim 12. wherein the polygon is displayed on a displayed nftap of the area 
1 0 identified by the address. 

14. The method defined in Claim 1, wherein the geographic area definition comprises a standard 
geography type from a list of displayed geography types. 

15. The method defined in Claim 14, wherein the geographic area definition further comprises a 
geography code or a nante of a geographical entity. 

15 16. The method defined in Claim 1 5, wherein the geography code comprises a zip code. 

17. The method defined in Claim 1, wherein the classification is part of a list of displayed 
classifications. 

18. The method defined in Claim 1, wherein the threshold value associated with the classification is 
part of a list of displayed threshold values. 

20 19. The method defined in Claim 1 . wherein the list of contact records comprises a mailing list. 

20. The method defined in Claim 1, wherein the list of contact records comprises a plurality of records, 
and wherein one of the records inchides at least one of the following: physical address, electronic address, telephone 
number, facsimile number, Internet Protocol address, pager number, network address or universal resource locator. 

21. The method defined in Claim 1, wherein the geography codes are a hierarchical component of a zip 

25 code. 

22. The method defined in Claim 1, wherein the spatial coordinate comprises an interieaved latitude 
and longitude. 

23. A real-time, interactive method of building a contact list based on selected criteria, the method 
comprising: 

30 permitting a user to interactively generate a list specification in real-time; 

transmitting the list specification over a network to a server having a memory; and 
building a contact list on the server in real-time based on the list specification, wherein the contact 
list comprises a plurality of records. 

24. The method defined in Claim 23, further including specifying an area of interest, wherein the area 
35 of interest may be of any size and any shape. 
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25. The method defined in Claim 23, further including specifying a product selected from a plurality of 
products and specifying a threshold score for the product. 

26. The method defined in Claim 25, wherein the threshold score for the product is indicative of a 
predetermined level of consumption of the product. 

5 27. The method defined in Claim 23, wherein building the contact list on the server includes: 

generating an intermediate list based on the fist specif icatioa* and 
approving the number of records in the intermediate list 
28. The method defined in Claim 21, wherein building the contact list on the server includes providing 
selected append data for the each of the records in the intermediate Bst if the numb^ of records is approved. 
10 29. The method defined in Claim 28, wherdn the append data includes at least one of the following: 

age, gender, mvXz\ status, estimated income, property vahie, ownership status, length of time at address, education 
level, occupation, presence of child, and age of child. 

30. The method defined in Claim 28, wherein providing selects! append data includes selecting at least 
one append data type from a list of append data types. 
15 31 . The method defined in Claim 27. further including pemnittino the user to select screening data. 

32. The method defined in Claim 31, wherein generating the intermediate list includes applying the 
saeening data. 

33. The method defined in Claim 31, further including selecting at least one screening data type from a 
list of screening data types. 

20 34. The method defined In Claim 23, wherein building the contact list on the server in real-time 

comprises building the list from a database stored in random access memory. 

35. The method defined in Claim 23, additionally comprising transmitting the contact list to a first 
client machine. 

36. The method defined in Claim 35, wherein transmitting the contact list includes approving a number 
25 of records in the contact list. 

37. The method defined in Claim 35, additionally comprising collecting information via a browser to 
generate the list specification. 

38. The method defined in Claim 37, wherein the browser collects the information at a second client 

machine. 

30 39. The method defined in Claim 38, wherein the first client machine and the second client machine are 

the same machine. 

40. The method defined in Claim 35, additionally comprising transmitting a message to electronic 
addresses listed in the contact list transmitted to the first client machine. 

41. The method defined in Claim 35, wherein the contact list is subject to one of the following 
35 restrictions: read-only usage, one-time usage, or unlimited usage. 
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42. The method defined in Claim 23, additionally comprising collecting information via an applet to 
generate the list specification. 

43. The method defined in Claim 23, further including: 
entering a desired address; and 

5 specifying a radius from the desired address. 

44. The method defined in Claim 23. further including: 
entering a desired location identifier; and 

specifying a polygon around a location identified by the location identifier. 

45. The method defined in Claim 44, wherein specifying the polygon includes drawing the polygon on a 
1 0 displayed map of the area identified by the address. 

46. The method defined in Claim 23, further including selecting a standard geography type from a list 
of standard geography types. 

47. The method defined in Claim 46, furth^ including entering a geography code or a nante of a 
geographical entity. 

1 5 48. The method defined in Claim 47, wherein the geography code comprises a zip code. 

49. The method define in Claim 46, wheren the standard gragraphy type is selected from the list of 
standard geography types inchjding zip codes, dominant mariceting areas, cities, places, counties, states, telephone 
area codes, minor civil divisions, metropolitan statistical areas, legislative districts, voting districts and school 
districts. 

20 50. The method defined in Claim 23, further including: 

selecting a product from a list of displayed products; and 
identifying a threshold score associated with the product. 

51 . The method defined in Claim 23, wherein one of the records of the contact list includes at least one 
of the following: at least a partial name, physical address, electronic address, telephone number, facsimile number, 

25 pager number, or universal resource locator. 

52. The method defined in Claim 23, wherein the contact list comprises a mailing list. 

53. The method defined in Claim 23, wherein the contact list comprises a household list, a business list 
or an individual list. 

54. A real-time, interacth/e method of building a contact list based on selected criteria, the method 
30 comprising: 

interactively generating a list specification in real-time; and 

building a contact list on a server in real-time based on the list specification record. 

55. The method defined in Claim 54, additionally comprising collecting information so as to generate 
the list specification at the server. 



•33. 



/ 



wo 02/29675 



PCTAJSOl/30863 



56. The method defined in Claim 54, wherein the contact list comprises a plurality of records, and 
wherein one of the records includes at least one of the following: physical address, electronic address, telephone 
number, facsimile number, Internet Protocol address, pager number, or universal resource locator. 

57. A real-time, interactive method of building a contact list on a computer network based on selected 
5 criteria, the method comprising: 

interactively generating a list specification in real-time, comprising: 

interactively specifying a geographically defined area for which a contact list is desired 
including receiving user input, and 

interactively selecting a product from a plurality of products and a threshold score for the 
1 0 product including receiving user input- 

transmitting the list specification over the compute network to a server having a monory; 
building the contact list on the server in real-time based on the list specification; and 
transmitting the contact list to a user-spedfi«i node on the computer network if one or more 
characteristics of the contact list are approved by a user. 
1 5 58. The method defined in Claim 57, wherein the characteristics of the contact list include a number of 

names/records on the contact list, the list specification for the contact list and a cost of the contact list. 

59. The method defined in Claim 57, wherein interactively generating a list specification in real-time 
further comprises interactively selecting additional data from a list of data appendable to the contact list. 

60. The method defined in Claim 57, additionally comprising: 
20 storing the list specification in a memory; and 

rebuilding the contact list at a predetermined future time based on the stored list specification. 

61. The method defined in Claim 60, wherein the stored list specttication corresponds to a selected 
business location of a multiple location business. 

62. The method defined in Claim 57, wherein building the contact list on the server in real-time 
25 comprises building the contact list from a database stored in random access memory. 

63. The method defined in Claim 57, wherein the contact list comprises a plurality of records, and 
wherein one of the records inchides at least one of the following: physical address, electronic address, telephone 
number, facsimile number. Internet Protocol address, pager number, or universal resource locator. 

64. The method defined in Claim 57, wherein interactivdy generating a list specification in real-time is 
30 performed on a user specification node on the computer network. 

65. The method defined in Claim 64, wherein the user specification node and the user-specified node 
are different nodes on the computer network. 

66. The method defined in Claim 57, wherein the contact list comprises a household list, a business list 
or an individual list. 
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67. The method defined in Claim 57, additionally comprising transmitting a message to electronic 
addresses listed in the contact list transmitted to the user-specified node. 

68. The method defined in Claim 57, wherein the contact list is subject to one of the following 
restrictions: read only usage, one-time usage, or unlimited usage. 

5 69. A computer system for interactively building a contact list in real time based on selected criteria, 

the system comprising: 

a user specification process module configured to receive user input so as to interactively generate 
a list specification in real-time; 

a geography list process module configured to receive the list specification and to generate a list of 
1 0 selected geography codes in real-time based on the list specification; 

a list sdect and data append process module configured to generate an intermediate list in real-tinr:e 
based on the list of selected geography codes and the list specification; and 

a contact item lookup process module configured to build a contact list in real-time based on the 
intermediate fist. 

15 70. The system defined in Claim 69, wherein a server transmits the contact list to a user-specified 

node on a communication network if one or more characteristics of the contact list are approved by a user. 

71 . The system defined in Claim 70, wherein the characteristics of the contact list include a number of 
records on the contact list the list spedfication for the contact list and a cost of the contact list. 

72. The syston defined in Claim 70, additionally comprising a client device connected to the 
20 communication network, wherein the client device comprises the user-specified node. 

73. The system defined in Claim 70, wherein the user-specified node transmits a message to electronic 
addresses on the communication network listed in the contact list. 

74. The system defined in Claim 70, wherein the contact list is subject to one of the following 
restrictions: read-only usage, one-time usage, or unlimited usage. 

25 75. The system defined in Claim 69, wherein the geography list process module, the list select and data 

append process module, and the contact item lookup process module are executed in real-time on a server having a 
memory. 

76. The system defined in Claim 69, additionally comprising a client device connected to a 
communication network, wherein the user spedftcation process module executes on the client device. 
30 77. The system defined in Claim 69, wherein the user specification process module accesses one of a 

plurality of geo-demographic profiles and a mapping database or a geography name database. 

78. The system defined in Claim 69, wherein the geography list process module accesses a geography 
equivalency file. 

79. The system defined in Claim 69, wherein the list select and data append process module accesses a 
35 product score table and a geography index. 
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80. The system defined in Claim 79. wherein the list select and data append process module further 
accesses a geo-demographic directory, a geography to spatial coordinate database, a list database, and a demographic 
attributes database based on the geography index. 

81. The system defined in Claim 80, wherein the spatial coordinates of the geography to spatial 
coordinate database comprise interleaved latitude and longitude pairs. 

82. The system defined in Claim 69, wherein the contact item lookup process module accesses an 
address coding guide and a name database. 

83. The system defined in Claim 69, wherein the geography codes are a hierarchical component of a zip 

code. 

84. The system defined in Claim 75, wherein the memory includes random access memory configured 
to store at least one database so as to fadlitate the reaMime execution of the process modules. 

85. The system defined in Claim 69, wherein the contact list comprises a plurality of records, and 
wherein one of the records includes at least one of the following: physical address, electronic address, telephone 
number, facsimile number, Internet Protocol address, pager number, network address or universal resource locator. 

86. The system defined in Claim 69, wherdn the contact list comprises a household list, a business list 
or an individual list. 
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